1. Field of the Invention
The present invention relates to the field of artifact version control and more particularly to merging artifacts in a version control system.
2. Description of the Related Art
Version control relates to the management of different versions of artifacts produced through repetitive editing by one or more end editors. Often referred to in the context of source code development, software model development and configuration management, version control involves the management of one or more documents when the documents are edited in succession, parallel or both by one or more editors. Put plainly, version control addresses one of two likely contingencies. In a first contingency, an editor applies edits to a document in succession and requires a view to changes in the document from an ancestor version to a contemporary version. In the other contingency, one or more editors concurrently apply different edits to the same document and the edits must be merged into a unified document.
Merging is a common operation when working with versioned artifacts in a version control system. Wherever two or more editors apply edits to the same version of a file in parallel, a merge is required to harmonize the edits the parallel artifacts. Merging unstructured textual artifacts can be a relatively simple operation because within an unstructured textual artifact, there is no relationship from one line to the next. By comparison, merging a structured artifact such as source code or markup can be trying, as the skilled artisan will attest.
Notably, when editing an artifact, a simple line to line change can affect the integrity of structures or objects specified within the artifact. In this regard, the more structural the file content, the worse the problem because relationships between structures within an artifact must be maintained during a merge operation in order to protect the integrity of the artifact. Exacerbating matters, each element in an artifact can have multiple properties, each of which can contain or reference one or more other elements in the artifact. As other relationships can exist only in source code, the structure of an artifact can become exceedingly complex—so much so that attempting to edit the artifact within a mere text editor can virtually guarantee the corruption of the artifact as has been demonstrated by sufficient empirical evidence.
Thus, more sophisticated visual merge tools have become the preferred mode of performing a merge operation. The use of a visual merge tool in a version control system, however, is not without its own set of challenges. In this regard, each individual change can appear within the visual merge tool as a single artifact difference referred to in the art as a “delta”. Yet, each individual change to an element in an artifact by a contributor reflected by a delta can be a candidate for conflict in view of a possible change to the same element by another contributor in another version of the artifact.
The typical merge user interface in a conventional visual merge tool includes multiple, concurrently displayed windows containing the merge contributors, often accompanied by an ancestor window and a merged file window. Some visual merge tools only optionally display the ancestor and the merged file, while others exclude the display of the ancestor and merged file entirely. Each approach is a compromise in usability designed to reduce clutter and to reduce the time taken to render the file content to the screen. In this regard, the clutter of multiple, concurrently displayed windows can be especially problematic when dealing with structured data viewed either hierarchically or diagrammatically as a substantial amount of screen real estate can be required to visualize all contributors and the merged model.
In order to accommodate the multiple, concurrent display of windows for the differences between the sources of change in structured data and the merged result, each window can be clipped and scroll bars enabled. In consequence, in order to visually identify the relevant differences in the structured data in each window, the end user must position the scroll bar controls to bring those differences into view in each window. The failure to do so will result in a difference going unnoticed and potentially unconsidered. Moreover, because different windows are used to visualize the differences, it is not possible always to place the windows in close enough proximity to one another to correlate differences in different windows. Consequently, to achieve correlation, the end user must mentally overlay the content of the different windows to visualize all differences.
Recognizing this deficiency, recent visual merge tools such as the Rational™ Software Architect™ version 6 manufactured by IBM Corporation of Armonk, N.Y., provides a software implementation of difference view overlay. The software implementation of the difference view overlay incorporates a button control in the compare view for the visual merge tool which when selected, displays a contributor or ancestor counterpart in any of the contributor or ancestor diagrams. Notwithstanding, the differentiation provided by the difference view overlay requires that the underlying model is rendered in a lighter color below the main model so as to allow the viewer to discern the two. As a result, while the overlay emphasizes positional changes, color and content changes can go unrecognized since the upper model hides the lower model.